• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    CHECK POINTS FOR A FILE SYSTEM. The present invention relates to checkpoints for a file system. In some respects, updates to the file system are organized in checkpoint memory bays. When a checkpoint is desired, subsequent updates are directed to another checkpoint memory compartment. After global tables have been updated for updates to the current checkpoint memory bay, a logical copy of the global tables is created. This logical copy is stored as part of the checkpoint data. To assist in recovery, a checkpoint manager can wait until all updates to the current checkpoint memory bay have been written to the checkpoint store before writing final data to the store. This final checkpoint data can refer to the logical copy of the global tables and includes a validation code to verify that the checkpoint data is correct.
    公开号:BR112012031912B1
    申请号:R112012031912-4
    申请日:2011-06-01
    公开日:2020-11-17
    发明作者:Jonathan M. Cargille；Thomas J. Miller；William R. Tipton
    申请人:Microsoft Technology Licensing, Llc；
    IPC主号:
    专利说明:

    Background
    [001] The present invention relates to a power failure or system failure may occur in the medium of recording data to a storage device. When this happens, the data may be lost or become inconsistent. For example, if a system fails in the middle of a transaction where the account holder withdraws money from an ATM, the transaction may unfairly favor the bank or the account holder. As another example, if a system fails during a very long calculation involving disk accesses, it can take a significant amount of time to redo the calculation.
    [002] The claimed matter is not limited to the modalities that solve the inconveniences or that work only in environments such as those described above. Instead, this foundation is provided only to illustrate an area of exemplary technology where some of the modalities described here can be practiced. SUMMARY
    [003] In summary, the aspects of the subject described here refer to checkpoints for a file system. In some respects, updates to the file system are organized in a checkpoint memory compartment (memory compartment). When a checkpoint is desired, subsequent updates are directed to another checkpoint memory compartment. After global tables are updated for updates in the current checkpoint memory bay, a logical copy of the global tables is created. This logical copy is stored as part of the checkpoint data. To assist in recovery, a checkpoint manager can wait until all current checkpoint memory compartment updates have been written to storage before writing the final checkpoint data to storage. This final checkpoint data can refer to the logical copy of the global tables and includes a validation code to verify that the checkpoint data is correct.
    [004] This summary is provided in a brief way to identify some aspects of the object which are further described in the Detailed Description. This summary is not intended to identify key or essential features of the claimed matter, nor is it intended to be used to limit the scope of the claimed matter.
    [005] The phrase "the matter described here" refers to the matter described in the Detailed Description, unless the context clearly indicates otherwise. The term "aspects" should be read as "at least one aspect". Identifying aspects of the material described in the Detailed Description is not intended to identify the key or essential characteristics of the claimed material.
    [006] The aspects described above and other aspects of the subject described here are illustrated by way of example and without limitation to the accompanying drawings in which similar reference numbers indicate similar elements and in which: BRIEF DESCRIPTION OF THE DRAWINGS
    [007] Figure 1 is a block diagram that represents an exemplary general purpose computing environment in which aspects of the subject described in this document can be incorporated;
    [008] FIGURE 2 is a block diagram that represents an exemplary arrangement of the components of a system, in which aspects of the matter described here can work;
    [009] FIGURE 3 is a block diagram that illustrates aspects of the subject described in this document;
    [0010] FIGURE 4 is a diagram that generally represents changes to a file system according to the aspects of the subject described in this document;
    [0011] FIGURE 5 is a block diagram illustrating exemplary checkpoint memory compartments according to the aspects of the subject described here; and
    [0012] FIGURES 6-8 are flow diagrams that generally represent exemplary actions that can occur according to the aspects of the matter described here. DETAILED DESCRIPTION DEFINITIONS
    [0013] As used herein, the term "includes" and its variants should be read as terms open to the public that mean "includes, but is not limited to". The term "or" should be read as "and / or" unless the context clearly indicates otherwise. The term "based" should be understood as "based, at least in part". The term "a modality" should be read as "at least one modality." The term "another variant" should be read as "at least one other modality." Other definitions, explicit and implicit, can be included below. EXEMPLARY OPERATING ENVIRONMENT
    [0014] Figure 1 illustrates an example of an appropriate computing system environment 100 on which aspects of the subject described in this document can be implemented. The computing system environment 100 is only an example of an appropriate computing environment and is not intended to suggest any limitations as to the scope or functionality of aspects of the subject described herein. Nor should computing environment 100 be construed to have any dependencies or requirements related to any or a combination of components illustrated in the exemplary operating environment 100.
    [0015] Aspects of the subject described here are operational with several other general-purpose or special-purpose computing system environments or configurations. Examples of well-known computer systems, environments or configurations that may be suitable for use with the aspects of the subject described here include personal computers, server computers, portable or laptop devices, multiprocessor systems, microcontroller-based systems, set-top boxes, electronics programmable, networked PCs, minicomputers, mainframe computers, personal digital assistants (PDAs), gaming devices, printers, devices, including set-top, media center, or other devices, in-car or in-car computing devices, other devices mobile, distributed computing environments, which include any of the above systems or devices, and the like.
    [0016] The aspects of the subject described here can be described in the general context of instructions executable by computer, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, and so on, that perform specific tasks or implement particular abstract data types. Aspects of the subject described here can also be practiced in distributed computing environments in which tasks are performed by remote processing devices that are connected via a communications network. In a distributed computing environment, program modules can be located on local and remote computer storage media, including memory storage devices.
    [0017] With reference to figure 1, an exemplary system for implementing aspects of the matter described here includes a general purpose computing device, in the form of a computer 110. A computer can include any electronic device that is capable of executing an instruction. The components of computer 110 may include a processing unit 120, a system memory 130, and a system bus 121 that couples to various system components, including the system memory to processing unit 120. The system bus 121 it can be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. For example, not limitation, architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA bus (EISA), Video Electronics Standards Association (VESA) local bus, Peripherical Component Interconnect (PCI) also known as Mezzanine bus, Peripherical Component Interconnect Extended (PCI-X) bus, Advanced Graphics Port (AGP) bus, and PCI Express (PCIe).
    [0018] Computer 110 typically includes a variety of computer-readable media. Computer readable media can be any available media that can be accessed by computer 110 and include both volatile and non-volatile media and removable and non-removable media. For example, and not limitation, computer-readable media may comprise computer storage media and communication media.
    [0019] Computer storage media include both volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable instructions, data structures, program modules or other data . Computer storage media includes RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, versatile digital discs (DVD) or other optical disc storage, magnetic tapes, magnetic tapes, magnetic disk storage or other devices magnetic storage devices, or any other means that can be used to store the desired information and that can be accessed by the computer 110.
    [0020] Means of communication typically incorporate computer-readable instructions, data structures, program modules or other data into a modulated data signal, such as a carrier wave or other transport mechanism and include any means of information delivery. The term "modulated data signal" means a signal that has one or more of its characteristics established or altered in order to encode the information in the signal. By way of example, and not limitation, communication media includes wired media, such as a wired network or direct wired connection and wireless media, such as acoustic, RF, infrared, and other wireless media. Combinations of any of the above must also be included within the scope of computer-readable media.
    [0021] System memory 130 includes computer storage media in the form of volatile and / or non-volatile memory, such as read-only memory (ROM) 131 and random access memory (RAM) 132. The Entry system / Basic Output 133 (BIOS), containing the basic routines that help to transfer information between elements inside the computer 110, as during startup, is normally stored in ROM 131. RAM 132, typically, contains data and / or program modules which are directly accessible to and / or currently being operated by processing unit 120. By way of example, and not limitation, Figure 1 illustrates operating system 134, application programs 135, other program modules 136, and data of program 137.
    [0022] Computer 110 may also include other computer storage media removable / non-removable, volatile / non-volatile media. By way of example only, Figure 1 illustrates a hard disk 141 that reads or writes to non-removable, non-volatile magnetic media, a magnetic disk drive 151, which reads from or writes to a removable magnetic disk, non-volatile 152, and an optical disc drive 155 that reads or writes to a removable, non-volatile optical disc 156, such as a CD-ROM or other optical media. Other removable / non-removable, volatile / non-volatile computer storage media that can be used in the exemplary operating environment include magnetic tape cassettes, flash memory cards, versatile digital discs, other optical discs, digital video tape, status RAM solid state, solid state ROM, and the like. Hard disk 141 is normally connected to system bus 121 via a non-removable memory interface, such as interface 140, and magnetic disk drive 151 and optical disk drive 155 are normally connected to system bus 121 by a removable memory interface, such as interface 150.
    [0023] The units and their computer storage media, associated discussed above and illustrated in figure 1, provide the storage of computer-readable instructions, data structures, program modules and other data on computer 110. In Figure 1, for example, hard drive 141 is illustrated as storage for operating system 144, application programs 145, other program modules 146, and program data 147. Note that these components may be the same or different from the system operating system 134, application programs 135, other program modules 136, and program data 137. Operating system 144, application programs 145, other program modules 146, and program data 147 are given different numbers here to illustrate that, in the minimum, they are different copies.
    [0024] A user can enter commands and information on computer 110 through input devices such as the keyboard and 162 pointing device 161, commonly referred to as a mouse, trackball or touchpad. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, a touchscreen, a recording tablet, or the like. These and other input devices are often connected to the processing unit 120 via an input user interface 160 which is coupled to the system bus, but can be connected by another interface and bus structures, such as a parallel port, game port or a universal serial bus (USB).
    [0025] A monitor 191 or other type of display device is also connected to the system bus 121 via an interface, such as a video interface 190. In addition to the monitor, computers can also include other peripheral output devices, such as speakers 197 and printer 196, which can be connected via a peripheral output interface 195.
    [0026] Computer 110 can operate in a network environment using logical connections to one or more remote computers, such as a remote computer 180. Remote computer 180 can be a personal computer, a server, a router, a network PC , a peer-to-peer device or other common network node, and typically includes many or all of the elements described above relating to computer 110, although only one memory storage device 181 has been illustrated in Figure 1. The logical connections described in Figure 1 they include a local area network (LAN) 171 and a wide area network (WAN) 173, but can also include other networks. Such network environments are common in M, company-wide computer networks, intranets and the Internet.
    [0027] When used in a LAN network environment, computer 110 is connected to LAN 171 through a network interface or adapter 170. When used in a WAN network environment, computer 110 may include a 172 or other modem means to establish communication over WAN 173, such as the Internet. Modem 172, which can be internal or external, can be connected to system bus 121 via input user interface 160 or another appropriate mechanism. In a network environment, the described program modules relating to computer 110, or parts thereof, may be stored on the remote memory storage device. As an example, and not a limitation, Figure 1 illustrates remote application programs 185 as residing on memory device 181. It will be appreciated that the network connections shown are exemplary and other means of establishing a communication link between computers may be used. Checkpoint
    [0028] As mentioned earlier, power failure and system failures can occur when writing data to a storage device. This can leave the data stored on the storage device in an inconsistent state. To solve this and other problems, checkpoints can be recorded on the storage device.
    [0029] FIGURE 2 is a block diagram that represents an exemplary arrangement of the components of a system, in which aspects of the matter described here can operate. The components illustrated in FIGURE 2 are examples and are not intended to be inclusive of components that may be necessary or included. In other embodiments, the components and / or functions described in conjunction with FIGURE 2 can be included in other components (shown or not shown) placed in subcomponents without departing from the spirit or scope of aspects of the matter described here. In some embodiments, the components and / or functions described in conjunction with FIGURE 2 can be distributed across multiple devices.
    [0030] As for FIGURE 2, system 205 may include one or more applications 210, an API 215, file system components 220, storage 250, a communication mechanism 255, and other components (not shown). System 205 may comprise one or more computing devices. Such devices may include, for example, personal computers, servers, portable or laptop devices, multiprocessor systems, microcontroller-based systems, set-top boxes, programmable consumer electronics, networked PCs, minicomputers, mainframe computers, cell phones, assistants personal digital devices (PDAs), gaming devices, printers, devices including set-top media center, or other devices, in-car or in-car computing devices, other mobile devices, distributed computing environments that include any of the systems or devices above, and the like.
    [0031] If system 205 comprises a single device, an exemplary device that can be configured to act as system 205 comprises computer 110 of FIGURE 1. Where system 205 comprises several devices, each of the various devices may comprise a computer 110 of FIGURE 1 configured similarly or differently
    [0032] The file system components 220 may include a recovery manager 225, a checkpoint manager 230, an I / O manager 235, a recording plan manager 237, and other components (not shown). As used herein, the term component is to be read to include all or part of a device, a set of one or more software modules or portions thereof, a combination of one or more software modules or portions of the same, and one or more devices or portions thereof, and the like.
    [0033] The communications mechanism 255 allows system 205 to communicate with other entities. For example, communication mechanism 255 may allow system 205 to communicate with applications on a remote host. Communications mechanism 255 may be a network interface or adapter 170, modem 172, or any other mechanism for establishing communications, as described in conjunction with FIGURE 1.
    [0034] Storage 250 is any storage medium capable of providing access to data. Storage can include volatile memory (for example, a cache) and non-volatile memory (for example, a persistent storage device). The term data is to be read widely to include everything that can be represented by one or more elements of computer storage. Logically, the data can be represented as a series of Ts and 0’s in volatile or non-volatile memory. On computers that have a non-binary storage medium, data can be represented according to the capacities of the storage medium. Data can be organized into different types of data structures, including simple data types, such as numbers, letters and the like, hierarchical, linked, or related data types, data structures, which include various other data structures or simple data types, and the like. Some examples of data include information, program code, program status, program data, other data, and the like.
    [0035] Storage 250 may include hard disk storage, other non-volatile storage, volatile memory, such as RAM, other storage, some combination of the above, and the like and can be distributed among several devices. Storage 250 can be external, internal, or include components that are both internal and external to the 205 system.
    [0036] Storage 250 may be accessed via a storage controller 240. Access, as used herein, may include reading data, writing data, deleting data, updating data, a combination including two or more of the above , and the like. Storage controllers 240 can receive requests to access storage 250 and can fulfill requests as appropriate. Storage controllers 240 can be arranged in such a way that it does not guarantee that data will be written to storage 250 in the order in which they were received. In addition, storage controllers 240 may indicate that it has written requested data before storage controller 240 has actually written data to the non-volatile memory of storage 250.
    [0037] The one or more 210 applications include any processes that may be involved in the creation, deletion or updating of data. Such processes can run in user mode or kernel mode. The term "process" and its variants, as used herein, may include one or more traditional processes, sequences, components, object libraries, which perform tasks, and the like. A process can be implemented in hardware, software, or a combination of hardware and software. In one embodiment, a process is any mechanism, however called, capable of or used to perform an action. A process can be distributed across multiple devices or a single device. One or more 210 applications can make file system requests (for example, via functions / methods) via API 215 to I / O manager 235.
    [0038] I / O manager 235 can determine which I / O request or requests to send to storage controller 240 (or some other intermediate component). I / O manager 235 can also return data for one or more applications 210 as operations associated with continuing, completing, or failing system requests. When a file system request involves a transaction, the I / O manager 235 can inform a transaction manager (not shown) so that the transaction manager can properly manage the transaction. In some embodiments, the transaction manager functions can be included in the I / O manager 235.
    [0039] File system components 220 can use copy on write, write in place, a combination of the above, and the like, when writing file system objects or metadata to file system objects on storage 250. The term "file" can include a directory, a file system object that has no children (for example, which is sometimes thought of as a file), other filesystem objects, and the like.
    [0040] In copy on save, before the data of a file is modified, a copy of the data that is being modified is copied to another location. In an on-site recording, the data in a file can be modified in place without copying the original data to another location. A copy-on-write-on-site hybrid may include making a copy-over-recording of metadata about a file during the recording run in place of the data included in the file.
    [0041] Objects in a file system can be updated in the context of transactions. A transaction is a set of operations that can be described by several properties, including, for example, atomic, consistent, isolated and durable. As used herein, a transaction can be defined by at least the consistent property and can also be defined by one or more of the other properties above.
    [0042] Consistent property refers to a state of data permission with respect to one or more files. Before a transaction begins and after a transaction is completed, files on a file system must be in an allowed state (although they can pass through disallowed states during the operation). For example, a bank transfer can be implemented as a set of two operations: a debit from one account and a credit to another account. Consistency in this example can be defined as having the combined bank account balance and the account holder being a constant (for example, T = A + B, where T is a constant, A = bank balance, B = account holding balance ). To implement consistency in this example, debit and credit transactions simply need to be for the same amount of money and want to either be completed or not completed on each account.
    [0043] A checkpoint can be recorded to indicate a file system consistency state. A checkpoint can include one or more validation codes (for example, one or more checksums, hashes, or other data) that can be used to determine whether the checkpoint and / or data associated with the checkpoint were correctly written to disc. When recovering, the last recorded checkpoint can be found. The checkpoint validation code (s) can then be used to determine whether the checkpoint and / or data associated with the checkpoint has been correctly written to the disk. If not, a previous checkpoint can be found and the validity checked until a valid checkpoint is found. Once the most recent valid checkpoint has been found, a last consistent state of the file system is known. File system operations that occur after this point can be discarded or additional recovery actions can be performed as desired.
    [0044] In one embodiment, an object in a file system can be denoted by Dn where n identifies the object for a system. Objects in the file system are serializable (that is, capable of being represented as data on storage 250) and detializable. An object table associates each object identifier with its location in storage 250.
    [0045] The first time that Dn is updated in a modification transaction, Dn is located by looking at its location in the object table using n. For use in an example, the Dn storage location in storage 250 is called L1.
    [0046] The contents of L1 are then read from storage 250, the object can be deserialized (for example, converted from the serialized format to an object structure), and the parts of the object that are to be modified are copied to main system memory. Updates are performed in portions (or copies) in memory. In conjunction with the memory portions to be modified, one or more new locations (calling this L2) in the storage are assigned to the modified portions.
    [0047] These copies in the main memory of the system are here called "logical copies" of the objects. A logical copy of an object includes one or more data structures that can be used to represent the object. Logically, a logical copy is a duplicate of an object. Physically, a logical copy can include data (including pointers to other data) that can be used to create a duplicate of the object. For example, in an application, a logical copy can be an actual copy (for example, bit-by-bit copy) of the object or a data structure that includes data that can be used to create the object.
    [0048] In another implementation, an unmodified logical copy may include one or more pointers that refer to the original object. As the logical copy is modified, pointers in the logical copy may refer to new memory locations (for example, to the altered portion of the logical copy), while other pointers may refer to portions of the original object (for example, to the unmodified portion of the logic copy). Using the pointers, the modified copy can be constructed using the modified data together with the unmodified data from the original object. Creating a logical copy can be performed, for example, to reduce the memory required to create a copy of an object.
    [0049] Furthermore, although serialization and deserialization are sometimes referred to here, there is no intention to limit the aspects of the matter described here, to what is usually considered as serialization and deserialization. In one embodiment, the serialized version can be bit-by-bit identical to the deserialized version. In another embodiment, the bits in the serialized version can be packaged in a different format and order than those in the deserialized version. In fact, in a modality, serialization and deserialization, they must be understood as meaning any data storage and retrieval mechanism, which represents objects from storage. The other mechanisms, for example, may include properties for recording objects in text format in storage, which encodes the properties of objects in a markup language in storage, other forms of property storage and other characteristics of objects in storage, and similar.
    [0050] At the system's discretion (for example, after a transaction or some other time), the system can serialize the modified logical copy back to the stable medium, but does so at the L2 location. The intention to save the modified logical copy back to the new location is called the recording plan. A recording plan can identify an arbitrary number of updates for one or more objects. A recording plan can refer to changes that occur in more than one operation. Multiple recording plans can be combined into a single recording plan.
    [0051] The recording plan manager 237 may be involved with creating recording plans for various updates. When a recording plan involves multiple file system objects (for example, in the context of a transaction), recording plan manager 237 can be operable to generate a recording plan that indicates the locations in the storage of all objects in the file system involve in the operation in order to maintain a consistent state for the file system.
    [0052] When a modification occurs right after a checkpoint, a block called a recovery block (which can be repeated in several locations) can be modified to point to the beginning of the modified logical copy (that is, L2). A field in the L2 object points to the location that will be recorded for the next one. This field represents a link in a chain of recording plans that occur between checkpoints.
    [0053] In conjunction with sending a request to save a logical copy, modification can be made to the object table. In particular, the position value indexed by the object identifier can be adjusted to the value of the location where the modified logical copy is to be stored (that is, L2). This is done so that a subsequent search for the location of the Dn object is referred to the L2 location, the new version of the object.
    [0054] If a transaction modifies more than one object, for example, Di and Dj, the objects are considered "atomically linked" to each other, and are recorded in a recording plan. A recording plan can specify this relationship (for example, in links to the objects involved).
    [0055] An arbitrary number of objects can be persisted in this way. Periodically, the object table can also be written to storage 250 in the same way as any other object.
    [0056] In conjunction with sending a request to write the object table to storage 250, a flush command can also be sent to storage controllers 240. A flush command instructs storage controllers 240 to write all data from their volatile memory that have not yet been written to the non-volatile memory of storage 250.
    [0057] Periodically, a checkpoint can be recorded in storage, as will be described in more detail below. A checkpoint can be indicated by a point recorder to be stored in storage 250. A checkpoint can be recorded at any time and can become stable / long after flush. Stable / durable refers to the checkpoint being stored in the storage's non-volatile memory.
    [0058] After a checkpoint is stable / durable, space used for any old copies and no use of objects (or parts of it) can be reused. Upon completion of the flush, the recovery block is then pointed to the beginning of a chain of the subsequent recording plans. In one embodiment, the recovery block can indicate the beginning of the recording plan chain for the new location of the object table.
    [0059] A more concrete example is described in conjunction with FIGURE 3, which is a block diagram that illustrates aspects of the matter described here. As illustrated, FIGURE 3 shows main memory 305 and storage 250. Line 307 represents a division between main memory 305 and storage 250. Objects above line 310 are in main memory, while objects below line 310 are in the volatile or non-volatile memory of storage 250.
    [0060] Objects 314 - 316 are shown in main memory 305. In the implementation, objects can be 314 - 316 deserialized logical copies of objects 319 - 321, respectively. Object 319 is located at position 1550 in storage 250, object 320 is located at position 200 in storage 250, and 321 the object is located at position 800 in storage 250.
    [0061] The object table includes 310 key-value pairs that indicate locations of objects 314 - 316 in storage 250. The key-value pairs are indexed using the identifiers (n) of objects 314-316.
    [0062] When a transaction modifies object 316 (for example, changing its name to foo.txt), consistency components (for example, consistency components 220 in FIGURE 2) can determine a new storage location for the updated object (for example, location 801). If the object is a file, updating its name in the context of a transaction can also cause the directory that includes the file to be involved in the transaction. For example, when a file name is changed, both the object that represents the file and the object that represents the directory that includes the file may have to be involved in the transaction. In this case, the directory that includes the object is represented as object 314 and a logical copy of the updated directory (for example, object 318) is represented as object 323 in storage 250. In addition, table 310 has been logically updated to table 311 to indicate the new storage locations (for example, 801 and 1000) of the modified objects (that is, objects 317 and 318).
    [0063] This modification of an object within the context of a transaction also affects another object that can be explicitly indicated or determined, for example, by I / O manager 235 or some other component of FIGURE 2.
    [0064] When two or more objects are involved in an update of a transaction, the objects are considered "atomically linked", as mentioned earlier. In a recovery operation, unless changes are found in storage 250 for all objects changed within the scope of the transaction, all detected changes are discarded. In other words, if a change to one of the objects is found, but a change to another object is not found, the changes to one of the objects are discarded.
    [0065] To atomically link two or more objects, in one embodiment, a pointer can be stored or otherwise associated with each object in storage 250. A pointer can indicate the storage location of another object (or part of it) involved in transaction. If there are no other objects involved in the transaction, the pointer can point to a "dead block" or indicate the location of a "head" object from another recording plane. This head object can include a recording plan, a modified object (or part of it) of the recording plan, or the like.
    [0066] In addition to pointers to nearby storage locations, data can also be stored in storage 250 to indicate the correct content of the "pointed" object. For example, a hash can be stored that indicates the correct content of a pointer pointed at the object.
    [0067] In the example shown in figure 3, a pointer associated with object 322 can point to a storage location associated with object 323. The pointer links the two objects. If, during recovery, either one of the objects is not found or does not have the correct content, the changes represented by the found objects can be discarded.
    [0068] Due to the nature of storage 250, there can be no guarantee as to which object will be written to the non-volatile memory of storage 250 first. If object 322 is written first and object 323 is not written, the pointer of object 322 will point to a storage location that may have spurious data. However, when calculating a hash of the data at the storage location and comparing this hash as the stored hash with object 322, the location data 1000 can be detected as having invalid data. In this case, during recovery, the recovery manager (for example, the recovery manager 225 of FIGURE 2) can download the changes represented by objects 322 and 323.
    [0069] Recovery block 330 points to the first storage location (in this case location 801) where the data should be stored after a checkpoint. Recovery block 330 may also include or be associated with a hash that is calculated using the correct contents of the object stored in the first storage location.
    [0070] FIGURE 4 is a diagram that generally represents changes that occur in a file system according to the aspects of the subject described here. Global tables 405 include an object table that identifies the locations of objects in storage and allocation data in relation to the space in storage 250 that has been allocated. 410 updates that are in progress are also illustrated. When an update touches time axis 415, the update is complete and you no longer need to modify any of the global tables 405. Each update line in updates 410 can represent multiple updates. Where multiple updates needed to be done together to maintain consistency, updates can be made in the context of transactions.
    [0071] For a checkpoint to be effective, the check needs to be recorded in a consistent state. With a copy on the recording file system, when an object is updated, a logical copy of the object as modified is stored in a new location on the file system. This new location is reflected in the object table with an update to the object table. For consistency, it would be incorrect for the object table to reflect an update that has not yet been written to disk, as the update may not be fully written to disk before a system failure. Likewise, it would also be incorrect for the update to be completed and written to disk and other transactionally related updates to be completed, but for the object table not to show the update.
    [0072] To ensure consistency, verification needs to be selected at a time in metadata for the update to be reflected in the global table. If each of the lines representing updates 410 indicates a period when global tables 405 can be updated for the update, then running a checkpoint at time 520 can produce an inconsistent state while running a checkpoint at time 525 it will yield a consistent state.
    [0073] FIGURE 5 is a block diagram illustrating exemplary checkpoint memory compartments according to the aspects of the subject described here. To address the issues mentioned above and other issues, each update can be associated with a checkpoint memory compartment (for example, one of the 515 memory compartments). A checkpoint memory bay is a logical concept that indicates that the global tables need to be updated to take into account at least update recording plans associated with the checkpoint memory bay prior to checkpoint data. checkpoint are written to the disc. In other words, the global tables need to be updated to account for the location and allocation information of updates to a memory compartment, although changes may or may not currently be saved in those locations.
    [0074] Periodically (for example, on the expiration of a checkpoint timer based on a recovery window, after a certain number of recordings have occurred, after some other limit is exceeded, or the like), the determination can be done to generate a checkpoint. When this happens, a checkpoint manager can update data (for example, data structure 510) that it tells the checkpoint memory compartment to associate with later updates. For example, the checkpoint manager can obtain an exclusive lock (for example, the 505 lock) on the data (for example, the data structure 510) that indicates the current checkpoint memory compartment. After the checkpoint manager has obtained an exclusive lock on the data, the checkpoint manager can update the data to indicate a new checkpoint memory compartment for later updates. All subsequent updates are associated with the new memory bay until the data checkpoint is changed to indicate another checkpoint memory bay in subsequent updates.
    [0075] A checkpoint memory compartment can be thought of as a logical concept and can be implemented in a variety of ways. For example, in an application, a checkpoint memory compartment can be implemented as a data structure, such as a list that has pointers to each of the changes associated with the checkpoint memory compartment. As another example, the checkpoint memory compartment can be implemented as the data held by each update where the data indicates the checkpoint associated with the update. As another example, the checkpoint memory compartment can be implemented as a counting traffic light. In this example, it may not be known, that updates still need to be written to disk, but a count of updates that still need to be written to disk is known. A read / write lock can be used in this example.
    [0076] The examples above are not intended to be all-inclusive or exhaustive of the ways of implementing a checkpoint memory compartment. Indeed, based on the teachings described herein, those skilled in the art can recognize many other mechanisms for implementing checkpoint memory compartments.
    [0077] After indicating the checkpoint memory bay for subsequent updates (for example, changing the data structure 510), the checkpoint manager can wait for recording plans for all updates in the memory bay of current checkpoint to be generated. After recording, plans for all updates to a current checkpoint memory bay are generated (but perhaps not written to storage), the checkpoint manager can take a snapshot of the global tables 405 in FIGURE 4 and create a recording plan to record the snapshot of the 405 global tables in storage. A snapshot can be created as a logical copy of the global tables 405 by copying on recording or other mechanisms.
    [0078] Returning to FIGURE 4, recording plans for later updates to the checkpoint can be generated and written to disk, while the checkpoint manager expects all updates to the current checkpoint memory bay to be generated and also while the checkpoint manager generates a recording plan to record a checkpoint. When the checkpoint manager seeks to take a snapshot of the global tables, however, the checkpoint manager can obtain an exclusive lock on the global tables 405 before creating the snapshot. While the checkpoint manager has an exclusive lock, recording plans can still be generated for other updates and these recording plans can still be stored in storage, but the global tables (for example, the object table) cannot be updated to point to these recording plans even after the checkpoint manager has released its exclusive lock. In conjunction with the release of the lock, the checkpoint manager can send a signal (for example, raise an event), which indicates that a later checkpoint has been enabled and that subsequent updates can update the global tables.
    [0079] To assist in recovery, the verification can be written to the disk with a validation code to validate the checkpoint according to the following rules: 1. Wait for data indicated in the recording plans to be written to disk (for example, expect all updates associated with the checkpoint to be written to disk); 2. Request that all data associated with the checkpoint be written to the disk (for example, request that the logical copy of the metadata be written to the disk); 3. Issue or wait for a flush and wait for confirmation that the flush has been completed successfully. 4. Generate a validation code for the checkpoint data that was written to the disk. In one embodiment, the validation code can be a subset of the data recorded on the disk. For example, if a file's data is stored in a tree where each node in the tree includes validation code for its children, then the validation code can be for the root node of the tree. In this mode, the validation code can be recorded with the root node and can also be used to verify that the validation code is correct.
    [0080] 5. Request that the validation code (and all associated data, such as the root node) be written to the disk. Note that the validation code cannot actually reach the disk before the system fails. If not, then the checkpoint is not a valid checkpoint.
    [0081] With these rules, during recovery, if the checkpoint is found in storage, as well as the checkpoint's internal validation code is valid, the other data associated with the checkpoint is also expected to be stored in storage and be valid. If the validation code is included in the root node, the other data in the root node (for example, pointers to the other nodes in the tree) can be used to find the rest of the corresponding data for the checkpoint.
    [0082] As an alternative, a validation code for each update associated with a checkpoint can be written to storage. For example, the scan may indicate blocks of all updates that should occur before the checkpoint and after the previous checkpoint. For each indicated block, the checkpoint can store a validation code that indicates the correct content of the block. During recovery in this alternative, to validate a checkpoint, each block can be validated against its associated checkpoint validation code.
    [0083] Returning to FIGURE 2, in one embodiment, the checkpoint manager 230 can be operable to perform the following actions, including: 1. Determine a first checkpoint to associate with requests to update file system objects . As mentioned earlier, checkpoint manager 230 can do this by updating a data structure (for example, data structure 510 of FIGURE 5) to point to a new checkpoint memory compartment. Then, as each subsequent request to update is received, the request can be assigned to the new checkpoint memory compartment.
    [0084] Note that the term "first", as used herein, does not mean the first checkpoint; instead, it is used to distinguish a “second” checkpoint. In other words, if there are N checkpoints, a first checkpoint can be any X where 1 <= X <= N and a second checkpoint can be any Y where 1 <= Y <= N and X <> Y. 2. Determine when to write checkpoint data associated with the checkpoint to the file system store. For example, a checkpoint timer can expire, a number of changes can be exceeded, or some other limit can be used to determine that it is time to record checkpoint data. 3. Determine a second checkpoint for subsequent requests to update filesystem objects. As mentioned earlier, checkpoint manager 230 can do this by updating the data structure (for example, data structure 510 in FIGURE 5) after obtaining an exclusive lock (for example, lock 505) on data structure. 4. Wait for a file system consistency state, allowing preparation to write data for subsequent requests. A consistent state occurs when all updates associated with the current checkpoint memory bay are represented (for example, they have been successfully written) to storage. Enabling preparation to write data for subsequent requests includes allowing recording plans to be generated and written to storage for subsequent requests, but not allowing metadata (for example, global tables) to be updated until after the logical copy of the metadata be created. 5. Create a logical copy of file system metadata. This can be done by taking a snapshot of the global tables as mentioned earlier. 6. Write the logical copy of the metadata to storage. In one embodiment, this may include requesting that the logical copy be written to storage and waiting for confirmation that the logical copy has been written to storage. In another embodiment, this may include marking the copy on storage as clean so that subsequent updates to the metadata will cause a copy on the recording before allowing updates. 7. Write at least one validation code to the store. As mentioned earlier, the validation code can be used to determine whether updates before the checkpoint have been written to storage, as well as whether the checkpoint recorder itself is valid.
    [0085] API 215 can receive a request to modify an object involved in a transaction. In response, I / O manager 235 can locate the object in a storage location (for example, L1) of the storage, create a logical copy of the object, make changes to the object in the context of the transaction, determine a second storage location (for example, L2) to store the logical copy as changed, send a request to save the logical copy as changed to storage controller 240, and update a volatile data structure (for example, object table 310) to indicate that the logical copy is stored in the second storage location.
    [0086] If API 215 receives a request to modify another object involved in the transaction, I / O manager 235 can perform additional actions, including creating an association (for example, a recording plan) that links the other object and the first object together. Then, in conjunction with sending a request to save changes to objects in storage, I / O manager 235 can also send a request to save association to storage controllers 240.
    [0087] Figures 6-8 are flow diagrams that generally represent exemplary actions that can occur according to the aspects of the matter described here. For simplicity of explanation, the methodology described in conjunction with Figures 6 - 8 is depicted and described as a series of acts. It should be understood and appreciated that aspects of the matter described in this document are not limited by the illustrated acts and / or the order of acts. In one embodiment, the acts occur in an order as described below. In other modalities, however, the acts may occur in parallel, in a different order, and / or with other acts not presented and described here. In addition, not all of the illustrated acts may be necessary to implement the methodology according to the aspects of the matter described here. In addition, those skilled in the art will understand and appreciate that the methodology can alternatively be represented as a series of interconnected states through a state diagram or as events.
    [0088] Returning to FIGURE 6, in block 605, the actions begin. In block 610, an indication is made that a first set of updates must be associated with a first checkpoint. This can be done by modifying a data structure to indicate that subsequent updates should be associated with a first checkpoint. This may involve, for example, obtaining and releasing a lock and updating a pointer or other data structure to refer to a checkpoint memory compartment, as mentioned earlier. Note that again "first" can mean any checkpoint in a file system and is used to distinguish this checkpoint from a subsequent checkpoint. For example, referring to Figures 2 and 5, checkpoint manager 230 can obtain lock 505 in data structure 510 and update the pointer to point to one of checkpoint memory compartments 515.
    [0089] In block 615, updates are received and associated with the first checkpoint. For example, referring to FIGURE 2, I / O manager 235 can receive update requests for application (s) 210 through API 215. As changes are received, they can be associated with a checkpoint.
    [0090] In block 620, a determination is made to record checkpoint data from the first checkpoint in the storage of a file system. For example, referring to FIGURE 2, checkpoint manager 230 can determine that a checkpoint timer has expired and can determine based on the same that a checkpoint should be written to storage 250.
    [0091] In block 625, the lock is obtained in a data structure for the indication of checkpoints for later updates. For example, referring to Figures 2 and 5, checkpoint manager 230 can obtain lock 505 in data structure 510.
    [0092] In block 630, the data structure is updated to refer to another checkpoint. The modification of this data structure indicates that changes that occur after the first series of changes are associated with a subsequent checkpoint. For example, referring to Figures 2 and 5, checkpoint manager 230 can update data structure 510 to refer to another of checkpoint memory compartments 515.
    [0093] In block 635, the block will be released. For example, referring to Figures 2 and 5, checkpoint manager 230 can release lock 505.
    [0094] In block 640, recording plans for the updates are generated. Each recording plan indicates at least one planned location in the data store that represents at least one of the first set of updates. For example, referring to FIGURE 2, recording plan manager 237 may be involved in creating recording plans for updates associated with a checkpoint.
    [0095] In block 645, metadata is updated for the recording plans. This metadata indicates storage locations for the recording plans (although the recording plans may or may not have been saved to storage at this time). For example, referring to FIGURE 2, recording plan manager 237 can update global tables to indicate object storage locations modified by recording plans.
    [0096] After block 645, the actions continue in block 705 of FIGURE 7. Moving to FIGURE 7, in block 705, a block is obtained for the metadata. For example, referring to FIGURES 2 and 4, checkpoint manager 230 can obtain a lock on global tables 405. Checkpoint manager 230 can wait until the metadata reflects the storage locations of all updates in the first set of updates (although all of these updates may or may not have been written to these storage locations).
    [0097] In block 710, a logical copy of the metadata is created. As mentioned earlier, this may involve creating a new copy of the metadata, marking the metadata as clean so that later updates to the metadata will cause a copy to be written, or some other logical copy mechanism. For example, referring to Figures 2 and 4, checkpoint manager 230 can make a logical copy of global tables 405.
    [0098] In block 715, the block will be released. For example, referring to Figures 2 and 4, checkpoint manager 230 can release a lock on global tables 405.
    [0099] In block 720, a recording plan to record the first checkpoint data is created. The creation of this recording plan can occur in parallel with the recording plans being generated (and recorded on the disc) for updates after the checkpoint, as well as data corresponding to the current recording plans being recorded on the disc. For example, referring to FIGURE 2, checkpoint manager 230 can use recording plan manager 237 to create a plan for recording checkpoint data from the first checkpoint. This data may include a logical copy of the previously mentioned global tables.
    [00100] In block 725, in one mode, the checkpoint manager can expect all updates to the first set of updates to be successfully written to storage. After all updates have been successfully written to storage, the update manager can then record a final checkpoint recorder that includes a validation code. As mentioned earlier, this allows recovery to simply check the validation code to determine whether any changes corresponding to the checkpoint that are expected have been written to storage.
    [00101] In another mode, the checkpoint manager can write several validation codes to a checkpoint register. These validation codes can be associated with the update storage locations of the first update set. In this mode, the checkpoint manager can wait for these updates to be written to storage or it can save the checkpoint recorder without waiting. If the latter option is chosen, finding a suitable checkpoint during recovery can be more involved than checking that a valid checkpoint register is on the disk.
    [00102] In block 730, checkpoint data can be saved in storage. This may involve, for example, recording a recording plan associated with the checkpoint data in storage. As another example, this may involve writing a checkpoint register to storage that refers to the logical copy of the global tables. For example, referring to FIGURE 2, checkpoint manager 230 may request that a recording plan corresponding to the checkpoint data be written to storage.
    [00103] In block 735, at least one validation code is written to the store. Writing at least one validation code to storage can be combined with writing a checkpoint record to storage that refers to the logical copies of the global tables. For example, referring to FIGURE 2, checkpoint manager 230 can write a storage checkpoint register that refers to the logical copies of the global tables and that includes a validation code to verify the content of the point register verification.
    [00104] In block 740, other actions, if applicable, can be performed.
    [00105] Returning to FIGURE 8, in block 805, the actions begin. At block 810, a recovery request is received. For example, referring to FIGURE 2, recovery manager 225 may receive a recovery request to perform recovery of data stored in storage 250.
    [00106] In block 815, the checkpoint data is located. For example, referring to FIGURE 2, recovery manager 225 can find the most recent checkpoint data stored in storage 250 (or some other storage).
    [00107] In block 820, the checkpoint data is validated using a validation code. For example, referring to FIGURE 2, the recovery manager 225 can calculate a checksum from the checkpoint data and compare this sum with the stored checksum with the checkpoint data. If the checksum matches, the check can be considered valid. If additional validation is desired, the recovery manager can attempt to validate one or more objects indicated by the global tables referred to by the checkpoint data.
    [00108] In block 825, other actions, if applicable, can be performed.
    [00109] As can be seen from the detailed description above, aspects have been described related to checkpoints for a file system. Although aspects of the subject described here are susceptible to various modifications and alternative constructions, certain illustrated modalities of them are shown in the drawings and have been described in detail above. It should be understood, however, that there is no intention to limit aspects of the claimed matter to the specific forms described, but, on the contrary, the intention is to cover all modifications, alternative and equivalent constructions that fall within the spirit and scope of the various aspects of the subject described here.
    权利要求:
    Claims (17)
    [0001]
    1. Method implemented at least in part by a computer characterized by the fact that it comprises the steps of: indicating that a first set of updates is being associated with a first checkpoint; determine the recording of checkpoint data in relation to the first checkpoint for a file system store that uses copy on write to update file system data; indicate that changes that occur after the first set of updates are associated with a subsequent checkpoint; generate recording plans for the first set of updates, each recording plan indicating at least one planned data storage location that represents at least one of the first set of updates; update metadata to indicate file system allocation data, as well as storage locations for file system objects modified by recording plans, create a logical copy of the metadata; create a recording plan to record data from the first checkpoint while allowing recording plans to be generated for subsequent updates in parallel with the creation of the recording plan, and write at least one validation code to storage, at least a portion of the checkpoint data validation code, at least one validation code usable to determine whether the first set of changes was correctly written to storage.
    [0002]
    2. Method, according to claim 1, characterized by the fact that it still comprises the step of waiting for data that represents the first set of changes to be written to storage before writing at least one validation code to storage.
    [0003]
    3. Method, according to claim 1, characterized by the fact that the step of writing at least one validation code to storage still comprises writing a single validation code to storage in a block with other data that refer to the root nodes at least one tree data structure, which represents the logical copy of the metadata, and also comprising the calculation of the unique validation code to validate the block.
    [0004]
    4. Method, according to claim 1, characterized by the fact that it still comprises the step of reading at least one validation code, computing at least one other validation code from the data in storage, comparing at least one code of validation with at least one other validation code, and determine based on it whether all data representing the first set of updates has been successfully written to storage.
    [0005]
    5. Method, according to claim 1, characterized by the fact that the step of indicating that a first set of updates is being associated with a first checkpoint comprises updating a data structure that indicates that the first checkpoint should be used for any update that occurs before the data structure is updated to indicate another checkpoint.
    [0006]
    6. Method, according to claim 5, characterized by the fact that it still comprises the step of obtaining an exclusive lock on the data structure before indicating that the updates that occur after the first set of updates must be associated with a subsequent checkpoint and release the exclusive lock after indicating that updates that occur after the first set of updates must be associated with a subsequent checkpoint.
    [0007]
    7. Method according to claim 1, characterized in that the step of determining the recording of the checkpoint data comprises determining that the synchronization of a checkpoint has expired, the synchronization of the checkpoint based on a window recovery.
    [0008]
    8. Method, according to claim 1, characterized by the fact that the step of creating a logical copy of the metadata comprises obtaining an exclusive lock on the metadata, indicating that any part of the metadata that is subsequently modified must be copied before being modified, and release the exclusive lock on metadata.
    [0009]
    9. Method, according to claim 1, characterized by the fact that the step of creating a logical copy of the metadata comprises creating the logical copy in parallel with the recording of the data representing at least one of the first set of updates in the storage.
    [0010]
    10. System comprises: a computer; an interface implemented at least in part by the computer and configured to receive a request to update a file system object from a file system; an I / O manager implemented at least in part by the computer and configured to determine one or more I / O requests to send to storage to fulfill the request, and a checkpoint manager implemented at least in part by the computer and configured to perform actions characterized by the fact that it comprises: determining a first checkpoint to associate with requests to update file system objects, where the checkpoint manager is configured to assign requests to different checkpoints; determine the recording of checkpoint data associated with the checkpoint to a file system storage device; determine a second checkpoint for subsequent requests to update file system objects; wait for a file system consistency state while allowing preparation to write data for subsequent requests; create a logical copy of file system metadata; write the logical copy to storage, and write at least one validation code to storage, at least one validation code configured to determine whether updates prior to the checkpoint have been written to storage; where the checkpoint manager is configured to determine a first checkpoint to associate with requests to update file system objects it is further configured to update a data structure that indicates that the first checkpoint must be used for updates that occur before determining the checkpoint data write associated with the checkpoint in a file system store and that the second checkpoint should be used for updates that occur afterwards.
    [0011]
    11. System according to claim 10, characterized by the fact that the checkpoint manager still configured to update the data structure is still configured to obtain an exclusive lock on the data structure before updating the data structure and release the exclusive lock after updating the data structure.
    [0012]
    12. System according to claim 10, characterized by the fact that the checkpoint manager still configured to determine the recording of checkpoint data associated with the checkpoint to a file system storage device is still configured to determine that a checkpoint time has expired, the checkpoint time based on a recovery window.
    [0013]
    13. System, according to claim 10, characterized by the fact that the I / O manager configured to determine one or more I / O requests to send to a storage to fulfill the request is further configured to create a logical copy of the file system object before sending one or more I / O requests to storage to update the file system object.
    [0014]
    14. System, according to claim 10, characterized by the fact that it still comprises a recording plan manager configured to generate a recording plan that indicates the storage locations of all file system objects being updated in in conjunction with the file system object to maintain a consistent state for the file system.
    [0015]
    15. System according to claim 10, characterized by the fact that the checkpoint manager configured to wait for a consistent file system state is further configured to wait until all updates associated with the first object of the checkpoint file system are represented in the file system storage.
    [0016]
    16. System according to claim 10, characterized by the fact that the checkpoint manager configured to allow the preparation to record data for subsequent requests is further configured to allow recording plans to be generated and recorded on the storage for subsequent requests, but not allowing the metadata to be updated until after the logical copy of the metadata is created.
    [0017]
    17. Computer storage medium having a method, characterized by the fact that it comprises the steps of: receiving a recovery request for a file system; locate checkpoint data for a checkpoint on a file system storage device, checkpoint data having previously been generated by actions, comprising: indicate that all updates that occur after updates associated with the checkpoint verification plans are assigned to a subsequent checkpoint, generate recording plans for updates associated with the checkpoint, each recording plan indicating at least one planned location in storage to represent at least one of the updates, update metadata to indicate locations of storing objects modified by the recording plans, creating a logical copy of the metadata, and writing at least one validation code to the storage for the checkpoint, and validating the checkpoint data using the validation code, the validation comprising calculating a checksum of the checkpoint data and co compare the checksum of the checkpoint data with the validation code.
    类似技术:
    公开号 | 公开日 | 专利标题
    BR112012031912B1|2020-11-17|method implemented by computer, computer system and storage medium
    US9430160B2|2016-08-30|Consistency without ordering dependency
    JP6026538B2|2016-11-16|Non-volatile media journaling of validated datasets
    US9448869B2|2016-09-20|Error detection for files
    CN109086388B|2020-12-29|Block chain data storage method, device, equipment and medium
    US9990150B2|2018-06-05|Method to provide transactional semantics for updates to data structures stored in a non-volatile memory
    Toney2019|Persitent Memory Test Framework
    同族专利:
    公开号 | 公开日
    US20120259816A1|2012-10-11|
    CA2803763C|2019-02-26|
    EP2583202A4|2017-03-15|
    KR101805948B1|2017-12-07|
    EP2583202A2|2013-04-24|
    RU2012154324A|2014-06-20|
    KR20130115995A|2013-10-22|
    US20150178165A1|2015-06-25|
    AU2011265653B2|2014-05-15|
    US20110307449A1|2011-12-15|
    BR112012031912A2|2016-11-08|
    TW201202981A|2012-01-16|
    WO2011159476A2|2011-12-22|
    US8224780B2|2012-07-17|
    JP5735104B2|2015-06-17|
    EP2583202B1|2022-01-12|
    CA2803763A1|2011-12-22|
    WO2011159476A3|2012-02-16|
    CN102934114B|2015-11-25|
    KR20170132338A|2017-12-01|
    RU2554847C2|2015-06-27|
    JP2013528883A|2013-07-11|
    CN102934114A|2013-02-13|
    AU2011265653A1|2012-12-13|
    TWI492077B|2015-07-11|
    US8924356B2|2014-12-30|
    KR101840996B1|2018-03-21|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    US4959771A|1987-04-10|1990-09-25|Prime Computer, Inc.|Write buffer for a digital processing system|
    US5963962A|1995-05-31|1999-10-05|Network Appliance, Inc.|Write anywhere file-system layout|
    DE69435146D1|1993-06-03|2008-11-13|Network Appliance Inc|Method and apparatus for describing arbitrary areas of a file system|
    US6035399A|1995-04-07|2000-03-07|Hewlett-Packard Company|Checkpoint object|
    US5864657A|1995-11-29|1999-01-26|Texas Micro, Inc.|Main memory system and checkpointing protocol for fault-tolerant computer system|
    US5907849A|1997-05-29|1999-05-25|International Business Machines Corporation|Method and system for recovery in a partitioned shared nothing database system using virtual share disks|
    US6185663B1|1998-06-15|2001-02-06|Compaq Computer Corporation|Computer method and apparatus for file system block allocation with multiple redo|
    US6449623B1|1998-09-04|2002-09-10|Lucent Technologies Inc,|Method and apparatus for detecting and recovering from data corruption of a database via read logging|
    JP2001101044A|1999-09-29|2001-04-13|Toshiba Corp|Transactional file managing method and transactional file system and composite transactional file system|
    US6571259B1|2000-09-26|2003-05-27|Emc Corporation|Preallocation of file system cache blocks in a data storage system|
    US6629198B2|2000-12-08|2003-09-30|Sun Microsystems, Inc.|Data storage system and method employing a write-ahead hash log|
    US7730213B2|2000-12-18|2010-06-01|Oracle America, Inc.|Object-based storage device with improved reliability and fast crash recovery|
    US6678809B1|2001-04-13|2004-01-13|Lsi Logic Corporation|Write-ahead log in directory management for concurrent I/O access for block storage|
    JP2003223350A|2002-01-29|2003-08-08|Ricoh Co Ltd|Data base system|
    US6993539B2|2002-03-19|2006-01-31|Network Appliance, Inc.|System and method for determining changes in two snapshots and for transmitting changes to destination snapshot|
    US20040216130A1|2002-08-30|2004-10-28|Keller S. Brandon|Method for saving and restoring data in software objects|
    US7457822B1|2002-11-01|2008-11-25|Bluearc Uk Limited|Apparatus and method for hardware-based file system|
    US7216254B1|2003-03-24|2007-05-08|Veritas Operating Corporation|Method and system of providing a write-accessible storage checkpoint|
    US7412460B2|2003-06-19|2008-08-12|International Business Machines Corporation|DBMS backup without suspending updates and corresponding recovery using separately stored log and data files|
    JP3798767B2|2003-06-26|2006-07-19|株式会社東芝|Disk control system and disk control program|
    US7721062B1|2003-11-10|2010-05-18|Netapp, Inc.|Method for detecting leaked buffer writes across file system consistency points|
    US7401093B1|2003-11-10|2008-07-15|Network Appliance, Inc.|System and method for managing file data during consistency points|
    US7054960B1|2003-11-18|2006-05-30|Veritas Operating Corporation|System and method for identifying block-level write operations to be transferred to a secondary site during replication|
    US7168001B2|2004-02-06|2007-01-23|Hewlett-Packard Development Company, L.P.|Transaction processing apparatus and method|
    US7664965B2|2004-04-29|2010-02-16|International Business Machines Corporation|Method and system for bootstrapping a trusted server having redundant trusted platform modules|
    JP4104586B2|2004-09-30|2008-06-18|株式会社東芝|File system having file management function and file management method|
    US7505410B2|2005-06-30|2009-03-17|Intel Corporation|Method and apparatus to support efficient check-point and role-back operations for flow-controlled queues in network devices|
    US7693864B1|2006-01-03|2010-04-06|Netapp, Inc.|System and method for quickly determining changed metadata using persistent consistency point image differencing|
    US20070234342A1|2006-01-25|2007-10-04|Flynn John T Jr|System and method for relocating running applications to topologically remotely located computing systems|
    WO2007091237A2|2006-02-06|2007-08-16|Filesx, Inc.|Long term backup on disk|
    US7769723B2|2006-04-28|2010-08-03|Netapp, Inc.|System and method for providing continuous data protection|
    US7870356B1|2007-02-22|2011-01-11|Emc Corporation|Creation of snapshot copies using a sparse file for keeping a record of changed blocks|
    US8495573B2|2007-10-04|2013-07-23|International Business Machines Corporation|Checkpoint and restartable applications and system services|
    TWI476610B|2008-04-29|2015-03-11|Maxiscale Inc|Peer-to-peer redundant file server system and methods|
    JP5425922B2|2008-10-30|2014-02-26|インターナショナル・ビジネス・マシーンズ・コーポレーション|Method, system, and computer program for performing data writing on a storage device|US8433865B2|2009-12-11|2013-04-30|Microsoft Corporation|Consistency without ordering dependency|
    US8793440B2|2010-06-17|2014-07-29|Microsoft Corporation|Error detection for files|
    US9155320B2|2011-07-06|2015-10-13|International Business Machines Corporation|Prefix-based leaf node storage for database system|
    US8776094B2|2011-08-11|2014-07-08|Microsoft Corporation|Runtime system|
    US9838415B2|2011-09-14|2017-12-05|Architecture Technology Corporation|Fight-through nodes for survivable computer network|
    US8543544B2|2012-01-06|2013-09-24|Apple Inc.|Checkpoint based progressive backup|
    FR2989801B1|2012-04-18|2014-11-21|Schneider Electric Ind Sas|METHOD FOR SECURE MANAGEMENT OF MEMORY SPACE FOR MICROCONTROLLER|
    KR102050723B1|2012-09-28|2019-12-02|삼성전자 주식회사|Computing system and data management method thereof|
    US9003228B2|2012-12-07|2015-04-07|International Business Machines Corporation|Consistency of data in persistent memory|
    US9304998B2|2012-12-19|2016-04-05|Microsoft Technology Licensing, Llc|Main-memory database checkpointing|
    US9766986B2|2013-08-08|2017-09-19|Architecture Technology Corporation|Fight-through nodes with disposable virtual machines and rollback of persistent state|
    US9769250B2|2013-08-08|2017-09-19|Architecture Technology Corporation|Fight-through nodes with disposable virtual machines and rollback of persistent state|
    US10002077B2|2014-01-31|2018-06-19|Hewlett Packard Enterprise Development Lp|Persistent memory controller based atomicity assurance|
    CN103984609B|2014-05-28|2017-06-16|华为技术有限公司|A kind of method and apparatus that checkpoint is reclaimed in file system based on copy-on-write|
    US10635504B2|2014-10-16|2020-04-28|Microsoft Technology Licensing, Llc|API versioning independent of product releases|
    US9892153B2|2014-12-19|2018-02-13|Oracle International Corporation|Detecting lost writes|
    CN106294357B|2015-05-14|2019-07-09|阿里巴巴集团控股有限公司|Data processing method and stream calculation system|
    US10031817B2|2015-11-05|2018-07-24|International Business Machines Corporation|Checkpoint mechanism in a compute embedded object storage infrastructure|
    US10284592B1|2015-12-17|2019-05-07|Architecture Technology Corporation|Application randomization mechanism|
    US10200406B1|2015-12-17|2019-02-05|Architecture Technology Corporation|Configuration of application randomization mechanism|
    US10007498B2|2015-12-17|2018-06-26|Architecture Technology Corporation|Application randomization mechanism|
    US10412116B1|2015-12-17|2019-09-10|Architecture Technology Corporation|Mechanism for concealing application and operation system identity|
    US10200401B1|2015-12-17|2019-02-05|Architecture Technology Corporation|Evaluating results of multiple virtual machines that use application randomization mechanism|
    US10412114B1|2015-12-17|2019-09-10|Architecture Technology Corporation|Application randomization mechanism|
    CN105930223A|2016-04-24|2016-09-07|湖南大学|Method for reducing size of check point file|
    KR101969799B1|2016-09-07|2019-04-17|울산과학기술원|Electronic device and controlling method thereof|
    CN108509460B|2017-02-28|2021-07-20|微软技术许可有限责任公司|Data consistency checking in distributed systems|
    US10554685B1|2017-05-25|2020-02-04|Architecture Technology Corporation|Self-healing architecture for resilient computing services|
    US20190102262A1|2017-09-29|2019-04-04|Intel Corporation|Automated continuous checkpointing|
    KR102022481B1|2017-12-06|2019-09-18|연세대학교 산학협력단|Method for Generating Checkpoint of High Performance Computing System Using GPU Usage|
    US10754785B2|2018-06-28|2020-08-25|Intel Corporation|Checkpointing for DRAM-less SSD|
    法律状态:
    2017-07-25| B25A| Requested transfer of rights approved|Owner name: MICROSOFT TECHNOLOGY LICENSING, LLC (US) |
    2018-12-26| B06F| Objections, documents and/or translations needed after an examination request according [chapter 6.6 patent gazette]|
    2020-07-07| B09A| Decision: intention to grant [chapter 9.1 patent gazette]|
    2020-11-17| B16A| Patent or certificate of addition of invention granted [chapter 16.1 patent gazette]|Free format text: PRAZO DE VALIDADE: 20 (VINTE) ANOS CONTADOS A PARTIR DE 01/06/2011, OBSERVADAS AS CONDICOES LEGAIS. |
    优先权:
    申请号 | 申请日 | 专利标题
    US12/815,418|2010-06-15|
    US12/815,418|US8224780B2|2010-06-15|2010-06-15|Checkpoints for a file system|
    PCT/US2011/038811|WO2011159476A2|2010-06-15|2011-06-01|Checkpoints for a file system|
    [返回顶部]